Method and apparatus for on demand video and other content rental

ABSTRACT

A video on demand system in the context of the Internet, for video rentals. A user accesses an on-line store to rent a video program or movie. The rental is for a limited time (such as 30 days) and within that thirty days, the video program or movie can only be viewed for a 24 hour time window. The time limits are enforced by the on-line store which maintains a database of each rental transaction and allows supply of the needed keys for decrypting the (encrypted) video or movie only if within the time limits.

CROSS REFERENCE TO RELATED APPLICATION

This application claims priority to U.S. provisional application61/010,763, filed Jan. 11, 2008 incorporated herein by reference in itsentirety.

FIELD OF THE INVENTION

This invention generally relates to video on demand and morespecifically to controlling use of video on demand content.

BACKGROUND

Video on demand is a well-known technology. It generally allows users toselect and watch digital video content over a network, such as cable TV,as part of an interactive television system. VOD systems either streamcontent allowing viewing in real time or download it in which theprogram is brought in its entirety to a set top box in the cabletelevision context before viewing starts. Most current video on demandsystems are in the context of cable and telephone company or satellitetelevision distribution systems. In most of these systems the user buysor selects a movie or television program and it begins to play in thetelevision set almost immediately. Typically a payment must be made foreach viewing.

Typically in the video on demand context, the commerce-related part ofthe transaction is similar to renting a video since viewing is strictlylimited in terms of time and/or number of viewings. In some video ondemand systems for instance one may watch the video as many times as onewants, but only beginning for a period of 24 hours beginning when therental is made. Such video on demand systems are very limited in termsof user control and access and they typically require viewing to beginimmediately upon purchase. This is due to the inherent limitations ofthe delivery system and the user's device which is typically a cabletelevision set top box or equivalent.

SUMMARY

In accordance with this disclosure, a video on demand system isprovided, not in the context of cable television, but instead in thecomputer network (Internet) context. It is known of course to purchase(or obtain without payment) video and audio material from a website viathe Internet, which is then downloaded partially or in its entirety tothe user's device typically a personal computer, or consumer electronicsdevice such as an iPod or Apple TV device or other such device. If theseare purchases the viewer then owns the content and can view it as manytimes as he wants indefinitely. However in the context of the systemdisclosed here, instead a video on demand approach is used in which theuser rents use of the audio or video material for a limited time for afixed payment and then can view the rented content at the time and placeof his choosing using his consumer electronics device, such as an AppleTV or iPod device. Some such devices may require connection to theInternet via a host computer.

Hence in one embodiment, the present system supports movie rental from,for instance, the Apple iTunes Store which is a central website,providing content. Users are able to rent movies or other video materialand view it on their Apple TV or iPod device. In some embodiments, thematerial may be transferred from one client (user) device to another.Typically upon purchase of the audio or video asset (program or movieand also referred to as content), a 30-day or other defined time periodbegins. The material may be viewed and/or listened to any time duringthat 30-day time. In addition, any time during that 30-day time when theviewer actually plays the material, a 24-hour window begins during whichunlimited viewing is permitted. However once that 24-hour window hasended no more viewing is permitted. Of course these time limits aremerely illustrative. In one embodiment, the present system supports bothhigh definition television and standard definition television. In oneembodiment, each individual program has its own assigned rental periodboth in terms of the overall time of rental such as the 30-day time spanand also the 24-hour window.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows the environment in which the present system operates.

FIG. 2 shows a flowchart showing the process of renting a movie in thisexample.

FIGS. 3A-3E shows various timelines for renting and viewing a movieunder different circumstances.

DETAILED DESCRIPTION

FIG. 1 shows the environment in which the present system operates. Mostelements here are conventional and hence not explained in furtherdetail. At the head end, there is a digital video on demand deliveryservice such as the iTunes Store 12 in one embodiment, more broadly aset of content and commerce servers operated by a commercial entity forstoring (or accessing) a number of programs and/or movies and/or audioitems such as music. This element 12 of the system is conventional sincefor instance such stores or more broadly content storage facilitiesalready exist. The iTunes Stores 12 is conventionally coupled to theInternet 14. Also connected to the Internet 14 at the user end is aclient device 18 indicated here as an Apple TV device, but which mightbe an Apple iPod device (with its host computer) or similar consumerelectronic devices or computers available from other manufacturers andwhich are currently available. Each such device 18 has as shown here aglobal universal identifier GUID 20 which identifies that particulardevice.

Also provided here at the head end is a conventional DRM (digital rightsmanagement) server 24. Such servers already exist in the content ofpresent video and audio downloads and viewing services. Digital rightsmanagement refers to the policy enforcement for protecting the contentfrom unauthorized use. Typically this involves some form of encryption.The content is transferred from the iTunes Store 12 or other source tothe client device 18 in encrypted form and must be decrypted at theclient device 18. Some such encryption schemes are sophisticated. Forinstance typically the encryption applied to each particular contenttransfer is different. Also the decryption keys supplied may be usefulonly for a small portion of each piece of content. In this case what isreferred to as a key bag or a file is provided as part of the DRM fileholding a number of keys for decrypting the content. The encryption maybe symmetric or asymmetric (public key-private key) as known in thefield. Typically the security information is provided in the form of aset of DRM data transferred along with or associated with the downloadedencrypted content and is necessary for decrypting and viewing same. TheDRM data includes conventionally data defining a security policyassociated with that content item, restricting a number of availableplays and device transfers. The commerce aspect of ordering the contentby the client device 18 is shown by the “rental order” from the clientdevice and is received via the Internet 14 at the iTunes Store 12 whichcharges the user of the client device 18 the appropriate rental to acredit card or other account. In response, the iTunes Store 12 providesthe “encrypted content” or asset along with at the same time or a latertime the relevant DRM data which is transferred to the client device 18.Generally, the encrypted content is downloaded from the iTunes Store 12to the client device 18 first, without the DRM data (including the keybag) needed to play the content. The DRM data is transmitted later,usually in response to the play request by the user, including the keybag as explained further below.

Also shown here is what is referred to as a content rental database andlogic 26. This element here is not present in conventional audio/videocontent purchase systems. Its operation is explained further below, butessentially it controls delivery of the relevant DRM data as so as toenforce the rental time limits. It may be resident on its own server orpart of the iTunes Store server(s) 12.

FIG. 2 shows in a flowchart the overall digital rights management for arental in accordance with this disclosure using the FIG. 1 system. Notshown here is the initial order by the user or the content encryptionwhich is conventional, since FIG. 2 shows the sequence of events at ahigh level. The initial action 32 here is that the movie (content)download is initiated to the user device 18 (after of course theordering procedure has been completed and the content encrypted.). Inthe next step 34 it is determined if at the present time the downloadhas been completed. This is a query made for instance every 5 seconds.If before the download is completed (“No”) the user has clicked “play”on his user device 18, that is he wants to start playing, the downloadis continued during playing. Thus this functions as a conventional videoon demand system where the user watches the video as it is beingdownloaded. However there is no requirement to do so. That is one mayalternatively download the content and watch it later. In this case ifafter the download is completed, the user has not yet clicked play, at36 a 30-day key or token (counter) is provided at the content rentaldatabase of FIG. 1. That is, this token expires in for instance 30 days.This time period is only an example here. This is the duration of therental time in this particular example.

The next step 40 is that at some time after the download begins andafter beginning of the 30-day period, the user does decide to play thecontent. This condition is checked periodically such as every 1 second.If at any particular time the user has not selected play, it isdetermined in the next step 42 if the 30 day token has expired. If “No”,control returns to the “user clicks play” step 40. If “Yes” at 42, themovie playback is disabled at the next step 46 because the 30-day rentaltime has expired. If the user however clicks play at 38 then the 24-hourwindow key or token is initiated at 48 at the content rental database.This begins the 24-hour viewing window. This is checked whether the userclicks play during the download or after the download. Then it ischecked periodically at 50 such as every 5 seconds if the 24-hours sincethe play was initiated has expired. If “No”, play is resumed. If “Yes”,the movie playback is disabled at the next step 46.

Thus in this particular example, the user has 30 days to view the movieafter the download begins. In one embodiment this time is a variabledesignated the rental duration. The user also has 24 hours in thisexample to view the movie after initiating the first play. (The 24 hourshere is only exemplary.) This variable is designated playback duration.Both of these variables may be unique to each asset as determined by thesystem operator and entered into the content rental database 26 for eachcontent item. Generally after the 30-day or 24-hour periods haveexpired, the item becomes unplayable due to expiration of its token.However if the time limit is hit while the movie is still playing, theplay will not be interrupted. Generally the play will be allowed tofinish, that is one can finish watching the movie as long as the movieis not stopped or paused by the user for the remainder of the movie.There is also provided generally both in the user device 18 and in termsof the tokens a pause function. That is one may pause viewing and thisalso stops the tolling of the 24-hour time limit. The pause time limitis for example 12 hours or for instance a number of times of the actualmovie duration.

Various time lines or scenarios for various circumstances of operationof the FIG. 2 method are shown in FIGS. 3A-3E which are largelyself-explanatory. In this case the horizontal line represents thepassage of time. Exemplary dates and times of day are shown for purposesof illustration. With reference to FIG. 3A, the first action at point 1is that the user makes rental and the 30-day rental time begins. Atpoint 2 (shaded), the customer actually starts to view (play) the movieand the 24-hour viewing window begins. There is unlimited playbackallowed during this 24-hour window, that is one may watch the movie orother item as much as one wants and as many times as one wants withinthe 24 hour window. The 24 hours expires at point 3, in this case 24hours after the initialization of play. The 30 days expires as shown atpoint 4. Of course in the typical situation the 30 day limit will not berelevant unless the 24 hours begins in the last day of the 30-daywindow.

FIG. 3B shows a similar situation as FIG. 3A except that in this casethe customer starts viewing the movie at 2 during the download (whichmay take for instance 30 minutes). Obviously in this case the 30-dayrental window at 4 is irrelevant. Note that typically downloading moviestakes a considerable amount of time due to the large amount of digitalinformation involved. In this case, the movie viewing window expires at3 24 hours after the beginning of the viewing time.

FIG. 3C shows the more complex situation where there is a pause involvedas an example of an implementation of the present method. Typicallypauses are initiated by the viewer when he wants to stop viewing and dosomething else and return to viewing later. As shown at point 1, thedownload is initiated and the 30-day window begins. At point 2, the userbegins to view the movie and his 24-hour window begins. Again he hasunlimited playback during this 24-hour window. At point 3, part waythrough the movie, the customer pauses the movie. In this case, hepauses it for two days until point 4 where he pushes the play button onhis consumer electronics playback device and resumes viewing. In thiscase, even though his 24-hour window has expired, the pausing enableshim to view the rest of the movie as long as he does not pause or stopthe movie again. The viewing period will then expire immediately aftercompletion of the movie. Again in this case point five which is the30-day rental window is irrelevant.

FIGS. 3D and 3E illustrate the situation where the viewing only beginsin the last 24 hours of the 30-day window. In FIG. 3D at point 1, thecustomer initiates the download and the 30-day rental window begins. Thecustomer however only starts to view the movie at point 2, 29 days intothe 30-day rental window. The 24-hour viewing window starts immediately.At point 3, the customer stops the movie. Normally the viewing periodwould have ended at point 4, which is the expiration of the 30-daywindow. At this point at 5, the customer attempts to resume watching themovie, but since the 30-day window expired he cannot watch it anymore.In another embodiment rather than the 30-day token dominating the24-hour token, the 24-hour token may be allowed to dominate in whichcase viewing may be continued as along as it is completed within 24hours of point 4. This would result in viewing terminating at point 5 inany situation.

FIG. 3E shows a variation on FIG. 3D where at point 1 the customerinitiates the download and the 30-day rental period starts. At point 2,the customer starts to view the movie in the 29th day of the 30-dayrental period. The 24-hour viewing window starts immediately. At point3, the customer pauses the movie and leaves his playback device onpause. Normally at point 4 the 30-day rental period would initially haveended. At point 5, the 24-hour window would have ended. However at point6, the customer resumes play by pushing the play button on his device.In this case, the 24-hour window has expired but the user may view theremainder of the movie as long as the movie is not paused or stoppedagain. The movie-watching period expires immediately after play iscompleted.

Note in certain embodiments, the content item may be transferred by theuser from one consumer electronics device to another as explainedfurther below. However the 30-day time period and 24-hour window stillobtain.

The following is directed to the DRM aspects and what is referred tohere as “check-in” and “check-out” procedures in accordance with thisdisclosure. This is explained in the context of the FIG. 1 system. It isunderstood that this is carried out in the context of a set of computerprograms typically part of the content rental database and logic withco-operating aspects in the DRM server and iTunes Store. These programsare readily coded in light of this disclosure. Typically they would becoded in for instance the C++ language, but this is merely illustrative.Of course the actual code being executed would typically be in compiledform. Moreover the actual encryption/decryption and other DRM aspectsare largely conventionally except as explained herein. Hence no furtherdiscussion is given of the encryption/decryption or other verificationand security aspects. Instead the focus here is on the present rentalaspect of the content as opposed to the conventional purchase/downloadapproach.

First, there is provided here what is referred to as a “rental bag” thatis part of the DRM for rentals. This entity is a set of data for eachrental transaction, and includes the following: a rental identification(rentalid) which is a unique identifier assigned by the content rentaldatabase to each rental transaction; an account identifier which is anidentifier for each user's iTunes account assigned by the iTunes Store;an identifier for the particular content item (program or movie) beingrented; and other DRM specific data, including the conventional key bag.This rental bag is illustrated in FIG. 1 and its use explained furtherbelow.

Also provided are three rental related processes referred to here asdeauthorization, check in and check out. Deauthorization occurs when auser who has rented a content item purchases a new computer or playbackdevice and wishes to transfer the rented item to the new computer ordevice. Check in is associated with deauthorization. Briefly, a transferinvolves checking in the rental item (to the content rental database)and then subsequently checking the same item out to the new (or another)device. Hence check in occurs when a user deauthorizes his old computeror device in favor of a new one, or when he transfers an asset (contentitem) from one device to another, such as from his computer to his iPod.A check in is followed by a check out, to the new or other device.

In more detail, check in involves the following actions, referring toFIG. 1. First, the iTunes client software (which is inherently residentin the iTunes client device 18) passes the rental bag, via the iTunesStore 12, to the content rental database and logic 26. The contentrental database and logic 26 (hereinafter “rental database”) checkswhether the rental bag is eligible for check in. If not, an errorindication is returned to the iTunes client. If eligible, the rentaldatabase sends the rental bag to the DRM server 24. The DRM server 24processes the rental bag and extracts from it and returns to the contentdatabase 26 the rentalid, the date of the first playback of the contentitem, and the user account identifier. The rental database checks in theitem then indicating the rental is terminated. In other words, itrenders that content item (as still resident on the iTunes playbackdevice 18 but in encrypted form) no longer playable. The rental databasethen sends the updated rental bag back to the iTunes client device 18.

The check out process occurs more frequently. Not only is it used as thesecond part of a transfer to complete the transfer, it is also invokedfor each new rental (content item download.) Also, the check out processis invoked in the case when the client device 18 attempts to play acontent item but does not have the requisite rental bag for decryption.For instance, this happens when the user attempts to play the itemduring the initial download. The check out process first requires theiTunes client device 26 to pass a rental bag (one received earlier bythe client in a prior rental transaction) to the database 26. Also sentis the client device GUID 20. The database 26 sends this data on to theDRM server 24. The DRM server 24 processes the rental bag and returns tothe database 26 the rentalid, the first playback time and date of thecontent item, and the user account identifier. The database 26 checks inresponse whether the rental bag is eligible for check out. Ifineligible, and error message is returned to the iTunes client device18. If eligible, the database 26 sends to the DRM server 24 the originalrental bag and the new data associated with the current content itembeing check out. This data includes the rental id, key(s), rentalexpiration date (30 days) and rental duration date (24 hour period). TheDRM server 24 in response formulates an updated rental bag with the dataassociated with the current content item being checked out, and sendthis updated rental bag to the database 26. The database 26 thenassociates the GUID (global universal identifier) and the rentalid ofthe updated rental bag in its database, thereby rendering that contentitem playable upon that device 18. The database 26 then sends theupdated rental bag to the client device 18.

Provided in one embodiment is a security check procedure to attempt todefeat hackers, who try to use the system in unauthorized fashion, suchas tampering with the content. This procedure is invoked for both checkin and check out and does require initially detection by the system oftampering; this detection is part of the DRM process.

For check in, when the client first accesses the rental database, anelement (“flag” in software terminology) is provided in the DRM dataindicating the possible detected tampering. The content database thensends the rental bag to the DRM server with this indication. The DRMserver then determines if there has been in fact tampering, and if sosends an indication (another flag) back to the content database. Thecontent database maintains a flag counter for this type of flag for eachitem, and increments the counter upon receipt of each such flag. If thecounter value exceeds a predetermined threshold, then that rentalid isexcluded so that content item for that device is rendered unplayable. Awarning or notice may be provided to the user at this point.

A similar security process is provided for the check out procedure. Thecheck out here is modified so that when the content database checkswhether the rental bag is eligible for check out, if it determines thatthe content item is already checked out to that GUID, then thetransaction is excluded. Further, if the flag counter value for therental is greater than the threshold, the transaction is excluded asabove. If the value of the flag counter is below the threshold, thecontent is allowed to be played but the counter value is incremented.Again, a warning or notice may be provided to the user.

In accordance with another aspect, two embodiments are provided forrespectively higher/lower levels of security. In the lower securityembodiment, when the user elects to play the rented content, therelevant key bag for the entire rented item is downloaded to his clientdevice and stored there. He can then play the content, even ifthereinafter his client device is no longer in communication with theiTunes Store (e.g., the client device is no longer connected to theInternet). In the higher security embodiment, the keys are downloadedonly as needed for each portion of the rented item, so the client devicemust remain in communication with the iTunes Store.

This disclosure is illustrative but not limiting. Further modificationswill be apparent to those skilled in the art in light of this disclosureand are intended to fall within the scope of the appended claims.

1-16. (canceled)
 17. A method comprising: transmitting a request forcontent to a server; receiving at least a portion of the content fromthe server in an encrypted form; receiving a rental key from the server,the rental key being valid for a first period of time during which playback of the content can be initiated; upon transmitting, to the server,a request to initiate play back of the content within the first periodof time, receiving, from the server, a decryption key that enables playback of the content over a second period of time; and receiving, basedat least in part on the first period of time associated with the rentalkey and the second period of time associated with the decryption key, atleast another portion of the content in encrypted form during the secondperiod of time.
 18. The method of claim 17, further comprising:decrypting the at least the portion of the content using the decryptionkey; and presenting, the decrypted at least the portion of the content.19. The method of claim 17, wherein the first period of time is thirtydays and the second period of time is twenty-four hours.
 20. The methodof claim 17, wherein the decryption key is transmitted in a key bag datastructure.
 21. The method of claim 20, wherein the key bag datastructure stores a plurality of decryption keys for decrypting aplurality of portions of the content in the encrypted form.
 22. Themethod of claim 17, wherein the decryption key is not received when therequest to initiate play back of the content is transmitted after thefirst period of time has expired.
 23. The method of claim 17, furthercomprising: receiving a security policy along with the decryption key,wherein the security policy specifies at least one of: a maximum numberof times the decryption key may be used to decrypt the at least theportion of the content over the second period of time, or a maximumnumber of client devices on which the decryption key may be used todecrypt the at least the portion of the content.
 24. The method of claim17, wherein the content comprises video content.
 25. The method of claim17, wherein the second period of time is different than the first periodof time.
 26. The method of claim 17, wherein, during the second periodof time, the decryption key enables play back of the content withoutcommunication with the server.
 27. The method of claim 17, wherein,during the second period of time, the decryption key enables play backof the content only when in communication with the server while playback occurs.
 28. The method of claim 17, wherein receiving the at leastthe other portion of the content comprises receiving a content streamthat includes the at least the other portion of the content.
 29. Anon-transitory machine-readable medium comprising code that, whenexecuted by one or more processors, causes the one or more processors toperform operations, the code comprising: code to transmit a requestassociated with accessing content to a server; code to receive, from theserver in response to the request, a rental key that is valid for afirst period of time during which play back of the content can beinitiated; code to, upon transmitting, to the server, a request toinitiate play back of the content within the first period of time,receive, from the server, a decryption key that enables play back of thecontent over a second period of time; and code to receive at least aportion of the content in an encrypted form; and code to decrypt the atleast the portion of the content during the second period of time usingthe decryption key.
 30. The non-transitory machine-readable medium ofclaim 29, wherein the code further comprises: code to display thedecrypted at least the portion of the content during the second periodof time.
 31. The non-transitory machine-readable medium of claim 29,wherein the code further comprises: code to receive a security policyalong with the decryption key, wherein the security policy specifies atleast one of: a maximum number of times the decryption key may be usedto decrypt the at least the portion of the content over the secondperiod of time, or a maximum number of client devices on which thedecryption key may be used to decrypt the at least the portion of thecontent.
 32. The non-transitory machine-readable medium of claim 29,wherein the content comprises video content.
 33. The non-transitorymachine-readable medium of claim 29, wherein the second period of timeis different than the first period of time.
 34. A device comprising: amemory; and at least one processor configured to: transmit a request fortime-limited access to content; receive, responsive to the request, thetime-limited access to the content, wherein the time-limited accesscomprises a first time period for initiating access to the content and asecond time period for accessing the content after initiating accesswithin the first time period; initiate access to the content within thefirst time period; and access at least a portion of the content withinthe second time period.
 35. The device of claim 34, wherein the contentis encrypted and the at least one processor is further configured to:receive a decryption key for accessing the content; and decrypt the atleast the portion of the content using the decryption key to access theat least the portion of the content within the second time period. 36.The device of claim 34, wherein the at least one processor is furtherconfigured to: access the at least the portion of the content within thesecond time period by receiving the at least the portion of the contentstreaming from a server.